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Abstract 

OAuth is the new de facto standard for delegating au¬ 
thorization in the web. An important limitation of OAuth is 
the fact that it was designed for authorization and not for 
authentication. The usage of OAuth for authentication thus 
leads to serious vulnerabilities as shown by Zhou et. al. in 
[44] and Chen et. al. in [9]. OpenID Connect was created on 
top of OAuth to fill this gap by providing federated identity 
management and user authentication. OpenID Connect was 
standardized in February 2014, but leading companies like 
Google, Microsoft, AOL and PayPal are already using it in 
their web applications [1], [2], [3], [30]. 

In this paper we describe the OpenID Connect protocol 
and provide the first in-depth analysis of one of the key 
features of OpenID Connect: the Discovery and the Dynamic 
Registration extensions. We present a new class of attacks on 
OpenID Connect that belong to the category of second-order 
vulnerabilities. These attacks consist of two phases: First, 
the injection payload is stored by the legitimate application. 
Later on, this payload is used in a security-critical operation. 

Our new class of attacks - called Malicious Endpoints 
attacks - exploits the OpenID Connect extensions Discov¬ 
ery and Dynamic Registration. These attacks break user 
authentication, compromise user privacy, and enable Server 
Side Request Forgery (SSRF), client-side code injection, and 
Denial-of-Service (DoS). As a result, the security of the 
OpenID Connect protocol cannot be guaranteed when these 
extensions are enabled in their present form. 

We contacted the authors of the OpenID Connect and 
OAuth specifications. They acknowledged our Malicious 
Endpoint attacks and recognized the need to improve the 
specification [29]. We are currently involved in the discus¬ 
sion regarding the mitigation of the existing issues and an 
extension to the OAuth specification. 

1. Introduction 

Single Sign-On (SSO). SSO protocols like SAML, OpenID 
or OpenID Connect replace multiple manual authentications 
at different Service Providers (SPs) with a single manual 
authentication at an Identity Provider (IdP), and multiple 


REST-based messages invisible to the End-User. An IdP 
manages identities of multiple End-Users, provides specific 
authentication mechanisms (e.g., usemame/password or 2- 
factor), and creates authentication tokens about authenti¬ 
cated End-Users. These authentication tokens are consumed 
by an SP granting or denying access to the End-User in 
dependence of the token verification. 

Security of SSO. Many known attacks on SSO systems 
only tamper with one protocol step and achieve the desired 
results in the following step. For example, replay-attacks, 
or attacks manipulating the token directly or sending it to 
a different SP [17], [20], [32], [41] - they all achieve their 
attack goals in a single protocol request/response pair. We 
thus classify these vulnerabilities as first-order vulnerabili¬ 
ties, since they can be detected by only checking a single 
control flow. Modern analyzing tools like SSOScan [44], 
AuthScan [5] and InteGuard [43] are able to detect such 
first-order vulnerabilities but are limited to one protocol or 
cover only a small subset of existing attacks. 

A more general approach is the automated analysis of 
SSO protocols, which remains a future challenge: Only 
the relatively simple flows of the SAML SSO protocol 
have been analyzed with protocol analyzers [17]. Sun et 
al. in 2012 [35] and Fett et al. in 2014 [15] proposed a 
formal model for analyzing OpenID and Browser ID, but 
admit that the protocols are far too complex to be analyzed 
automatically. 

Sunnnarized, previous work concentrated on first-order 
vulnerabilities in SAML [ /], [20], [32], OpenID [24], [40], 
[35], OAuth [9], [34] and Facebook Connect [21], [44], but 
the OpenID Connect protocol and especially its extensions 
have not been investigated so far. 

OpenID Connect. OpenID Connect is a new SSO protocol 
released in February 2014. It is the successor of OpenID and 
it is based on OAuth, but uses several ideas from OpenID. 

The key feature of OpenID — the dynamic and fully 
automatic open trust establishment between IdP and SP — 
is also present in the OpenID Connect protocol by means of 
the Discovery and Dynamic Registration extensions. Open 
in the context of SSO means that users can be logged 
into an SP even if the user’s IdP is not known to the SP 
beforehand. A user can simply submit its identity on the SP, 


which is usually a URL (e.g., https://IdP.com/alice) or an 
email address (e.g., alice@Idp.com). Based on this identity 
the SP discovers the responsible IdP (e.g., https://ldP.com/) 
and retrieves all information needed for the authentication. 
Afterwards, the SP dynamically registers on the discovered 
IdP and establishes a trust relationship to be able to (retrieve 
and) verify the authentication tokens used later on in the 
SSO protocol flow. 

During Discovery and Dynamic Registration, SP and 
IdP communicate directly with each other (server-to-server 
communication), so these protocol messages cannot be mon¬ 
itored by the End-User. 

Second-Order Vulnerabilities in OpenID Connect. 

Second-order vulnerabilities have been described and de¬ 
tected in the context of web applications [ ], [11], [27]. 
Speaking of second-order vulnerabilities in SSO protocols 
in general we have the same execution scheme: (1.) The 
injection of the attack vectors is allowed by the specification 
and protocol flow. Thus, no implementation or configuration 
flaws are required. (2.) The execution of the protocol can 
proceed as usual without any incidents. (3.) The attack 
vectors are loaded and lead to successful execution of the 
attack. 

Analyzing and detecting second-order vulnerabilities in 
distributed systems like SSO is more complex than in web 
applications, because they are including multiple phases, 
plethora messages, parameters and participants. This makes 
detection significantly more complex. We are not aware of 
any previous work and any automated security tools capable 
to detect such vulnerabilities. 

Malicious Endpoint Attacks. The concept of our Malicious 
Endpoint attacks abuses a weakness in the Discovery and 
Dynamic Registration extensions of the OpenID Connect 
protocol to initially store the payload on the SP and execute 
it in another step. The main reason for this is that an SP 
can be forced to start a Discovery on an attacker-controlled 
Webserver, which returns attacker-chosen information. This 
information contains URL parameters that can be used for 
different threats. For instance we could use them to start 
Server Side Request Forgery (SSRF) targeting the internal 
network behind the SP, execute Denial-of-Service (DoS) 
attacks by forcing the SP to download huge data files, start 
code injection attacks, and even broke the user authentica¬ 
tion on the SP — we were able to steal the user’s SSO 
token. 

Our Contribution. 

► We are the first providing an in-depth security anal¬ 
ysis of the OpenID Connect features Discovery and 
Dynamic Registration. 

► We identified serious second-order vulnerabilities and 
developed a new class of attacks called Malicious 
Endpoints attacks, which exploit a lack in the OpenID 
Connect specification resulting in SSRF, DoS, and 
authentication flaws. 


► We propose countermeasures to prevent our attacks, 
and discuss their respective advantages and disadvan¬ 
tages. The integration of our countermeasures are cur¬ 
rently discussed with the authors of the specification. 

► We provide a public available online website that can 
be used by SPs for verifying the security against our 
Malicious Endpoint attacks.^ 

Our results show that protocol extensions must be designed 
with extreme care, and their security implications have to 
be discussed thoroughly. Otherwise, they can lead to serious 
attacks with critical impact, even in secure standards. 

The Discovery and Dynamic Registration are optional 
extensions. Four libraries are officially certified to specific 
conformance profiles and interoperability [16]. We success¬ 
fully verified our attacks against two of them: MITREidCon- 
nect and phpOIDC. However, it must be considered that our 
Malicious Endpoints attack targets on the OpenID Connect 
specification itself and not on a specific implementation. 
Thus, any implementation using the Discovery and Dynamic 
Registration extensions is vulnerable against the class of 
Malicious Endpoints attacks. 

2. Modern SSO Protocols 

Since their establishment in the early 1980s, protocols 
like Kerberos (first officially published in 1987 as Version 
4 [22]) and the corresponding concepts of delegated authen¬ 
tication and authorization using Trusted Third Partys (TTPs) 
have been constantly developed and refined into modern 
SSO protocols. These protocols aim at being compliant with 
the requirements of the modern and flexible Internet infras¬ 
tructure. Mainly, modem SSO protocols strive to achieve the 
following goals: 

(1) Decentralization - SSO appears to be centralized 
embracing only a very small set of fixed TTPs. The most 
widely known of these TTPs are Facebook and Google. 
However, exporting data and outsourcing infrastructure to 
companies like Facebook and Google can include certain 
security risks and tmst issues. 

Luckily, modern protocols like OAuth, SAME, 
BrowserlD, OpenID and OpenID Connect are designed and 
specified to set up custom TTPs, which act independently 
from each other. This enables companies to set up their 
own TTPs and use these for authentication purposes instead 
of having to rely on external providers. 

(2) Trust Establishment - Every SP has to establish a 
tmst relationship with the TTP. In order to do this, key 
material has to be exchanged. An important requirement 
for modem SSO protocols is that this process occurs with 
minimal configuration, implementation, and installation ef¬ 
fort. In the best case, the trust establishment should work 
automatically. 

1. The website does not provide any tests against DoS and SSRF attacks 
in order to avoid misuse. 


2.1. OpenID Connect 

The OpenID Connect protocol efficiently addresses the 
goals stated above - it is decentralized and allows automated 
trust establishment without any configuration effort or user 
interaction. 

OpenID Connect was designed on basis of the OAuth 
framework [31] in order to enable the authentication of 
End-Users without changing the OAuth protocol flow. Thus, 
OAuth capabilities are integrated with the protocol it¬ 
self [36], providing OpenID Connect with the capability of 
delegated authorization. 

Additionally, OpenID Connect also incorporates con¬ 
cepts utilized by another SSO protocol - OpenID [39]. Such 
concepts are the Discovery and Dynamic Registration of 
OpenID Providers (OPs). The Discovery process allows an 
SP to automatically discover new OPs without any con¬ 
figuration and user interaction. The Dynamic Registration 
enables the on-the-fly registration and trust establishment 
between a Client and OP, also without any user interaction. 

A major advantage of OpenID Connect is its integration 
into existing applications: OpenID Connect was designed to 
be easily integrated into current OAuth compliant systems, 
with only minimal extensions to the already available OAuth 
APIs. 

2.2. Roles 

Within the OpenID Connect protocol, three different 
parties each assuming a different role can be found. The 
relationship between the different roles can be seen in 
Figure 1. 





End-User 

Figure 1: Role Relationship within the OpenID Connect 
protocol [36, Section 1.3] 


by OP, which proves the identity of the End-User. Op¬ 
tionally, the Client can also request authorization to access 
certain protected resources of the End-User stored on OP, 
for example, photos. 

Please note that the term “Client” according to OpenID 
Connect terminology denotes an SP according to the com¬ 
mon SSO terminology - a service, which can be accessed by 
the End-User. In order to be compliant to the terminology 
within the OAuth and OpenID Connect specification, we 
will use the term “Client” from now on. 

The OpenID Provider (OP) acts as a TTP/IdP towards 
Client and End-User, handles End-User authentication and 
issues an authentication token containing a specific set of 
claims proving the identity of the End-User. Additionally, 
an authorization token can be issued, in order to authorize 
the Client to access End-User’s resources. 

2.3. OP Endpoints 

Within the OpenID Connect Core specification [36] the 
following endpoints on the OP are defined and their relation 
to the according SSO phases is depicted in Figure 2: 

(1.) Registration Endpoint (regEndp): In order to use 
OpenID Connect services for authentication, a Client 
has to register on the OP. For this registra¬ 
tion, the Client accesses this URL regEndp, e.g., 
https://google.com/register. 

(2.) Authorization Endpoint (authEndp): In order to execute 
the Authentication Request of the Client, the End-User 
has to be redirected to the authEndp of the OP, e.g., 
https://login.google.com/. Here, the End- 
User has to authenticate to the OP via a corresponding 
authentication process and authorize the Client to ac¬ 
cess the requested resources. 

(3.) Token Endpoint (tokenEndp): The Client 

communicates with the tokenEndp, e.g., 
https://google.com/consume-token, 
in order to obtain the id_token described in 
Section 2.5 and authenticate the End-User. In addition, 
an access_token can be sent to the Client in order 
to authorize the access to restricted resources. This 
communication is done directly between Client and 
OP (without involving the End-User). 

(4.) Userinfo Endpoint (userinfoEndp): returns information 
about the authenticated End-User like email, address, 
phone, gender etc. In order to access the resources 
the Client uses an Access Token obtained through the 
OpenID Connect authentication. 


The End-User, represented by his user agent (UA), 
wants to access selected services of a Client. Therefore, he 
needs to prove his identity to the Client. Additionally, the 
End-User has the possibility to authorize the Client to access 
a specific set of his resources stored on the OP. 

The Client is an application providing a certain ser¬ 
vice, which requires authentication of an End-User. This 
authentication process is delegated to the corresponding OP. 
Therefore, the Client requests an authentication token signed 


2.4. Information Flow 

OpenID Connect contains three phases, as shown in 
Figure 2. In this section we explain the information flow 
during the different phases. 

Phase 1: Client Registration. The Client initially com¬ 
municates with the OP’s registration endpoint (regEndp). 
It submits the domain(s), where the Client is deployed. 
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Figure 2: Information flow in OpenID Connect containing three phases: Client Registration, User Authentication on the OP 
and Client Authorization, and User Authentication on the Client. 


for example https://clientA.com. The OP then generates a 
random client_id/ client_secret pair, stores them 
both together with the domain as a triplet, and sends the 
credentials to the Client. The Client stores the same infor¬ 
mation in order to use it during phases 2 and 3. 

The Client’s registration is mostly processed only once 
and is usually done via the web interface of the OP, for 
example by the domain administrator or the developer of the 
Client. Thus, the registration needs user interaction, causes 
management overhead, and cannot be executed automati¬ 
cally. 

Phase 2: User Authentication on the OP. In the context of 
delegated authentication the Client redirects unauthenticated 
End-Users to the Authorization service endpoint on the 
OP (authEndp). Subsequently, the End-User authenticates 
to the OP using his credentials. Then, the OP generates an 
authorization code and sends it to the End-User. The code 
is an intermediary between the End-User and the Client. By 
sending the code to the Client, the End-User authorizes the 
Client to access restricted resources. 

Once received, the Client uses the code to retrieve the 
authentication token (id_token), containing user’s iden¬ 
tity, and optionally the access_token granting access to 
restricted resources. 

Phase 3: User Authentication on the OP - ID and Access 
Token. Once the Client receives the code, it sends it to the 
Token Service endpoint on the OP (tokenEndp). In the same 
message, the Client sends its credentials (client_id and 
client_secret, cf. Phase 1) and authenticates to the 
OP. 


The OP responds with the id_token and possibly 
the (optional) access_token. Once the id_token is 
received, the Client verifies it and subsequently authenticates 
the End-User. 

The optional access_token is part of the OAuth 
protocol flow and it authorizes the Client to access restricted 
resources of the End-User on the OP. 

2.5. ID Token 

The OpenID Connect protocol is basically an extension 
of OAuth by adding an id_token. The id_token is a 
security token containing claims about the identity of an 
End-User by an OP, proving the End-User’s identity to a 
Client. Its data structure is represented as a ISON Web 
Token (JWT) [19]. In order to provide authenticity as well 
as integrity of the token, the OP is responsible for signing 
it using ISON Web Signature (JWS) [18]. 
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Listing 1: An example of ID Token as ISON object. 

A signed id_token consist of three parts: Header, 
containing information regarding the used cryptographic 


Header: { "alg" 

Body: { 

: "HS256" } 

" i s s " : 

"http://openidConnectProvider.com/" , 

"sub": 

"userl" , 

"exp": 

1444148908, 

"iat": 

1444148308, 

"nonce" 

: "40c6b33b9a2e", 

"aud": 

"http://client.com/" , 

/ 

Signature: AF45JF93LKD76D.... 













































algorithms, Body, including information needed for the au¬ 
thentication of an End-User, and Signature providing the 
authenticity and integrity of the id_token. 

Identity of the End-User. The identity of the user consists 
of two parts: (1.) issuer and (2.) subject. The issuer 
(cf. Listing 1: iss. Line 3) is a mandatory identity claim 
identifying the originator (the OpenID Provider) of the 
id_token, for example https://www.myOpenIDProvider. 
com. The subject (sub. Line 4) is a mandatory iden¬ 
tity claim that specifies the End-User’s identifier and is 
consumed by the Client. Issued by the OpenID Provider 
(issuer), it has to be locally unique and never reassigned 
(e.g., alice@myOpenIDProvider.com). It is essential 
to note that both values - issuer and subject - must 
be used to uniquely identify the End-User. 

Timestamps and Freshness. The claims timestamp 
(iat. Line 6) and expired (exp. Line 5) define the 
creation and expiration times of the token. The nonce 
(Line 7) claim is a randomly chosen String value, sent by 
the Client within the Authentication Request and passed 
through unmodified to the id_token, used to mitigate 
replay attacks. 

Audience Restrictions. The audience (aud. Line 
8) is a mandatory claim specifying the audience(s) 
that this id_token is intended to be used for (e.g. 
https://clientA.com). It must, at least, contain the 
client_id of the Client which requests the token. 

3. Security Model 

This section will give a detailed description of the se¬ 
curity model used in the analysis of the OpenID Connect 
protocol. 

3.1. Assumptions 

We make the following assumptions for the analyzed 
systems: 

► Secure TLS channels: A huge proportion of the security 
of OpenID Connect is based on the assumption that 
Transport Layer Security (TLS) is used to secure the 
communication between the involved parties. Naturally, 
we follow this approach and assume the corresponding 
TLS channels to be secure. 

► Uncompromised software: All software used by the 
End-User is assumed to be uncompromised. This espe¬ 
cially holds for the user agent and the operating system 
- we assume that no malicious web browser plugins 
and that no keyloggers etc., are active on the End- 
User’s system. We additionally assume that the Client 
and the OP can also not be compromised. Lor example, 
we assume that we do not have any other access except 
for their publicly available website (e.g. we do not have 
shell access). 


► No impersonation towards the End-User: The attacker 
controls his own webservers and services, but we as¬ 
sume that he does not impersonate legitimate web 
applications. We thus assume that the End-User can 
neither be tricked into accepting attacker generated 
TLS certificates as valid certificates for genuine Clients, 
nor will the End-User react to Phishing mails claiming 
to originate from the legitimate Client. 

In short, we assume the attacker must not able to 
impersonate a legitimate Client towards the End-User 
in any meaningful way. 

3.2. Capabilities of the Attacker 

The attacks to-be-introduced in this work have been 
strictly verified in the web attacker model [6]. In contrast 
to the network-based attacker model (also called the crypto¬ 
graphic attacker model), the web attacker does not have full 
control over the network and thus is unable to eavesdrop on 
or manipulate network connections. 

He is, however, able to use a UA or a custom HTTP 
client to send arbitrary HTTP requests to every publicly 
available web application in the web (including the Client 
and the OP) and subsequently receive its responses. 

Lor tests within live implementations the attacker is able 
to register as many accounts on a specific Client or OP as 
he wishes. 

Lurthermore, the attacker can use links (e.g., sent via 
email) or web-blog commentaries to lure the victim into 
opening a (manipulated) Uniform Resource Identifier (URI) 
to, for example, conduct CSRL attacks. 

3.3. Attacker Goals 

The scope of this paper are attacks against the End-User 
and attacks against the Client. 

Attacking the End-User. Attacks on the End-User are 
focusing on token theft. In OpenID Connect, there are 
three different tokens: The code, the id_token and the 
access_token. Leakage of any of them can allow an 
attacker to get unauthorized access to restricted resources. 

Attacking the Client. Attacks on the Client have different 
surfaces and can be categorized in two groups. 

The first group contains impersonation attacks. In Phase 

1 of the OpenID Connect protocol - during the registration 
- the Client receives the client_id and the client_- 
secret. Both parameters are used for the Client’s authen¬ 
tication to the OP. If these credentials are compromised, the 
attacker can use them to impersonate the Client. In Phase 

2 of the protocol, the Client receives at least one token. An 
attacker can then send manipulated tokens to the Client in 
order to impersonate different End-Users. 

The second group contains classical attacks on web 
applications. These attacks include DoS techniques as well 
as code injection attacks, like XSS or SQL-Injection. Please 
note that in our work, we consider this group of attacks only 
in conjunction of the OpenID Connect protocol. Thus, only 


attacks that are directly initiated through protocol messages 
are investigated. 

4. Gap in Security Evaluations 

By considering previous work regarding the security of 
SSO protocols, we observed that its analysis concentrates 
on Phase 2 and Phase 3 [34], [44], [9]. Concentrating on 
those two phases seems plausible, because the End-User 
authenticates in Phase 2 and the authentication tokens are 
transmitted in Phase 3. An attacker targeting Phase 2 or 
Phase 3 can achieve one or more of the goals defined 
in Section 3.3. As a result, previous work only revealed 
security vulnerabilities in Phase 2 and Phase 3. These were 
fixed and the specification was changed [9]. 

Nevertheless, the entirety of Phase 1 has not been con¬ 
sidered so far. This is reasoned by the fact that the Client 
Registration and Key Transport between Client and OP are 
usually executed manually. For instance, the developer of a 
Facebook App has to visit his Facebook developer website, 
and click on create new App. Facebook will then generate a 
client_id and a client_secret. The developer then 
copies them into his App configuration manually. 

In contrast to this manual execution, protocols like 
OpenID and OpenID Connect can also execute the Client 
Registration automatically. Especially for OpenID Connect, 
this issue is addressed by introducing a new approach for the 
Client registration: The so called Dynamic Registration [38] 
allows registration to be automatic, transparent and without 
any user interaction. However, an important security ques¬ 
tion raised about this development is: How does this feature 
affect the security of the protocol? 

5. Second-Order Vulnerabilities in OpenID 
Connect 

In this section we first describe the OpenID Connect 
extensions Discovery and Dynamic Registration in detail. 
Then, we present security considerations regarding the usage 
of the both phases. Based on the security considerations 
we introduce the concept of a novel class second-order 
vulnerabilities in SSO. 

5.1. OpenID Connect: Discovery and Dynamic 
Client Registration 

The information flow during the automated Client Regis¬ 
tration is shown in Figure 3. Initially, the End-User submits 
his identity, for example alice@honestORcom, to the Client. 
In order to initiate the SSO authentication, the Client needs 
to discover the corresponding OP controlling the identity of 
Alice. 

Phase 1.1. The Client uses the provided identity and ex¬ 
tracts the domain name of the OP [37, Section 2.1]. In 
our example, Alice’s identity is controlled by the domain 


honestOP.com. The domain name uniquely identifies the 
corresponding Discovery endpoint^. 

The Client sends an HTTP request to this Discovery 
endpoint and subsequently retrieves the OP’s configuration 
information including its endpoint locations: The (Dynamic) 
Registration Endpoint (regEndp), the Authorization End¬ 
point (authEndp), the Token Endpoint (tokenEndp) and fur¬ 
ther endpoints (c.f.. Section 2.3). 

Phase 1.2. In Phase 1.2 (Dynamic Registration) the 
Client can automatically register at the OP. For that 
purpose, the Client sends its own URL, for example 
http://client.com, to the regEndp URL. The OP 
responds with a client_id/ client_secret pair. Fi¬ 
nally, the Client and the OP store the credentials in their 
respective databases and use them during the next phases. 

5.2. Influence of the Discovery phase on the 
OpenID Connect flow 

By analyzing the Discovery and Dynamic Registration 
phases we make the following observations: 

► The usage of any OPs is supported by the OpenID Con¬ 
nect protocol without any pre-configuration, installation 
or manual interaction (neither on the Client nor on the 
User-Agent). The End-User has to enter his identity 
on the Client, e.g. bob@honestOP . com, in order to 
start the authentication with his own OP. 

► All discovered endpoints are URLs. No limitations are 
specified that restrict these URLs to domains, subdo¬ 
mains, or URL contexts. 

Based on our observations, we discovered that we can 
trigger any Client supporting Discovery and Dynamic Reg¬ 
istration to use our custom OP for authentication. Thus, we 
control the data sent to the Client and used in the following 
phases of the protocol flow. In Figure 4 we present how the 
retrieved information during the Discovery phase influences 
the OpenID Connect phases. 
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Figure 4: A detailed overview of the Discovery phase re¬ 
vealing how the metadata received by the Client influences 
the next OpenID Connect phases. 

The first two messages are used to discover the URL 
where the metadata of the OP is stored based on the 

2. This is usually realized by applying a modifier to the domain, e.g., 
https:/ /honest OP. com/.well-known/webfinger. 
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Figure 3: OpenID Connect Dynamic Registration 


identity entered by and End-User. The Discovery request 
(1.1.1) is an HTTP message sent to the OP’s discovery 
service (e.g. https://honestOP.eom/.well-known/webfinger). 
The response is a JSON message containing two param¬ 
eters: (1.) href, which points to the metadata of the OP 
and (2.) rel, which identifies the type of service (e.g. 
http:// openid.net/ specs/ connect/1.0/is suer). 

Consequentially, a new HTTP request is sent to the URL 
specified via the href parameter. The response contains the 
metadata with all information regarding the OP: endpoints, 
supported authentication flows, supported algorithms for 
signing and encrypting messages, public keys of the OP 
etc. 

Figure 4 depicts the relation between the endpoints 
received in the last messages of the Discovery phase and 
the OpenID Connect phases. The regEndp will be used by 
the Client in order to register the Client on the OP and 
receive the client credentials (e.g. client_id/client_secret). 

The authEndp points to the Authorization server respon¬ 
sible for the authentication of the End-User. Noteworthy is 
the fact that only the Authorization server is visible for the 
End-User during the authentication. All other endpoints are 
called by the Client directly and thus cannot be seen by the 
End-User. 

The next three endpoints tokenEndp, userInfoEndp and 
jwksEndp are used in the last Phase (Phase 3) of the proto¬ 
col: the End-User authentication. 

5.3. Security considerations 

OpenID Connect supports the usage of custom OPs. 
For that purpose, a Client uses the Discovery and the Dy¬ 
namic Registration Phase to retrieve the OP’s configuration 
information including the endpoints regEndp, authEndp, 
tokenEndp I userInfoEndp I jwksEndp and registers on it. 

Please note that a malicious Discovery service can freely 
choose all these parameters (cf.. Phase 1.1 in Figure 3). By 
this means, the malicious Discovery service can influence 
(1.) on which URL the Client registers (regEndp), (2.) which 
URL is used by the End-User to authenticate (authEndp), 


(3.) and to which URL the token will be finally sent (toke- 
nEndp/userlnfoEndp). 

5.4. Second-Order vulnerabilities in OpenID Con¬ 
nect 

Based on the security considerations, we developed a 
new class of attacks referred to the second-order vulnera¬ 
bilities. This new class differ from the class of conventional 
second-order vulnerabilities in the context of XSS, SQL- 
Injection and DoS. To clarify the difference we first explain 
how second-order vulnerabilities are exploited in general 
and then we introduce second-order vulnerabilities in dis¬ 
tributed systems like SSO protocols. 

Web application. Connnon second-order vulnerabilities in 
web applications as shown in [11], [27] have only three 
entities involved: (1.) the attacker acting with his browser, 
(2.) the server hosting the web application and (3.) option¬ 
ally another End-User (the victim). In case of DoS attacks 
as shown in [27], there is no third entity involved, since the 
victim is the server hosting the web application itself. 

Figure 5 shows an example of a second-order vulnera¬ 
bility on a web application. 
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Figure 5: Data flow of a conventional second-order vulner¬ 
ability on an web application. The attack vector is first 
placed, and later on executed leading to security issues. 

During the first step, the user input containing an attack 
vector will be stored in the database of a web application. 




















































In this step, no attack, but its preparation will be processed. 
Later on, the stored attack vector will be pulled from the 
database and executed leading to an SQL-Injection, XSS or 
even DoS. 

OpenID Connect. Second-order vulnerabilities in SSO pro¬ 
tocols are more complex than on web applications, since the 
attack consists of multiple steps and messages exchanged 
between different participants, for example, End-User and 
Client, Client and OP, and End-User and OP. Due to the 
nature of SSO, we have more entities: (1.) the End-User 
who wants to login. This can be either a benign End-User 
or the attacker; (2.) the Client which is the main target of 
our attacks; (3.) a honest OpenID Provider (OP); (4.) an 
attacker hosting his own service on the Internet. We will 
use this service to host a malicious Discovery service later 
on. 

Eigure 6 shows the data flow within a second-order vul¬ 
nerability in a SSO protocol. Initially, the attacker stores the 
attack vectors. The main difference is that the user input a is 
not the attack vectors, a just starts the SSO authentication. 
The injection of the attack vectors occurs during Phase 1 
of the protocol - the Discovery phase within a Server-to- 
Server communication. The attacker returns data used later 
on during the protocol. In case of OpenID Connect this is 
a metadata file containing endpoints of the OP, supported 
protocol flows and supported cryptographic algorithms. 



Eigure 6: Data flow of a second-order vulnerability in 
OpenID Connect. User’s input a triggers the authentication. 
Within the Server-to-Server communication in Phase 1, the 
attack vectors will be placed. These will be used later during 
Phase 2 or/and Phase 2. Please note that the contacted 
discovery services depends on the value of a. 

Later on, the stored attack vectors /3i,..., will be 
loaded. Please note that each attack vector can be used 
during different SSO phases. Thus, /3i,are used during 
Phase 2 of the protocol resulting. They can either lead 
to successful completion of this phase or to an successful 
attack. The further attack vectors /Sj, will be used in 

Phase 3 and lead to security issues. 

To sunnnarize, in Step 1 the attacker can place a harm¬ 
less^ payload on the Client in such a way that the further 
communication process between the participants is influ¬ 
enced resulting in the following issues: 

3. Harmless in this context means that the payload is not directly 
executed. 


(1.) The attacker gets access to resources owned by an 
benign End-User (Section 6.1). 

(2.) The attacker gather sensitive information regarding the 
Client (Section 6.2)and thus breaking privacy?. 

(3.) The attacker injects further attack vectors like XSS or 
SQL-Injection (Section 6.3). 

(4.) The further communication process between Client and 
End-User or Client and OP is slowed down significantly 
due to a DoS attack (Section 6.4). 

6. Malicious Endpoints Attacks 

This section describes four different attacks, which be¬ 
long to the class of Malicious Endpoints attacks. All at¬ 
tacks use the malicious Discovery service and influence the 
OpenID Connect flow. Since each attack pursues different 
goals, we describe for each attack the main goal, the setup 
including the attacker model and the attack itself. 

6.1. Broken End-User Authentication 

The idea behind the attack is to influence the information 
flow in the Discovery and Dynamic Registration Phase 
in such a way that the attacker gains access to sensitive 
information. The attacker pursues the theft of the credentials 
between the honest OP and the honest Client. Additionally, 
he steals a valid code authorizing the Client to access End- 
User’s resources on the honest OP. 

Setup. The basic setup for the attack is as follows: 

► The End-User {victim) has an active account on the 
genuine honest Client. We assume that the End-User 
trusts this Client and the Client follows the OpenID 
Connect protocol rules. 

► The End-User is registered at the honest OP on the 
domain https://honestOPcom. The End-User trusts this 
OP and the OP also follows the OpenID Connect 
protocol rules. 

► To perform the attack, the attacker has to set up 
his own Discovery service running on the domain 
http://malicious.com. This Discovery Service acts ma¬ 
liciously in that it deviates from the OpenID Connect 
protocol flow as described in Eigure 3. Note that there is 
no need to disguise http://malicious.com as the regular 
Discovery service belonging to the honest OP in any 
way. 

► According to the attacker model, the attacker does not 
hold any control over the honest Client, the End-User, 
the honest OP or the network traffic between these 
instances. The attacker is able to send an HTTP request 
through End-User’s browser, e.g. by embedding an im¬ 
age in a benign HTML website that causes the browser 
to automatically issue a request when the website is 
viewed. 

Attack description. In the following, we describe the attack 
protocol flow, which we depicted in Eigure 7. 
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Figure 7: Malicious Endpoints attack: Attacker’s Discovery service sets the endpoint variables in a specific way, such that 
the secret tokens sent in the third phase are seamlessly distributed to the attacker’s server. 


Phase 1.1 - Injecting malicious endpoints The attacker’s 
intention in the first phase is to force a valid Client to use the 
attacker’s malicious Discovery service. For this purpose, he 
constructs a malicious link and stores it on a benign website, 
e.g. in a web forum. For example, this can be a link to the 
valid Client containing an identity alice@malicious.com. 

issuer: http://malicious.com 

regEndp: https://honestOP.com/register 

authEndp: https://login.honestOP.com/ 

tokenEndp: http://malicious.com 

userinfoEndp: http://malicious.com 

Listing 2: Endpoints returned by the malicious Discovery 
service 

By visiting the website containing the malicious link, an 
HTTP request will be sent to the Client through the End- 
User’s (victim’s) browser. Consequentially, the Client starts 
a discovery phase with the malicious Discovery service 
http://malicious.com. The Client sends a request to deter¬ 
mine the corresponding endpoints. The attacker’s Discovery 
service responds with the following values, initiating the 
actual attack: 

Phase 1.2 - Dynamic Registration In the next step, the 
Client accesses regEndp for the Dynamic Registration. It 
sends a registration request to https://honestOP.com/register 
and receives a client_id and client_secret in the response. 

Note: The Client automatically starts the Dynamic Reg¬ 
istration, even if it is already registered on the honest OP. 
The reason for this behavior is that the Client believes 
that http://malicious.com is the responsible OP, since it is 
not known from previous authentication procedures. Thus, 
http://malicious.com is a new OP for the Client and it starts 
the registration procedure. 


Phase 2 - End-User Authentication and Authorization 
In the next phase, the Client redirects the End-User to 
authEndp, https://login.honestOP.com/, where the End-User 
has to authenticate himself and authorize the Client. The 
End-User is not able to detect any abnormalities in the 
protocol flow: Phase 1.1 and Phase 1.2 cannot be observed 
by the End-User, and in Phase 2 the End-User will be 
prompted to authenticate to the honest OP and authorize 
the honest Client, both of which he knows and trusts. Thus, 
the End-User authorizes the Client and the OP generates the 
code, which is sent to the Client. 

Note: Phase 2 exactly follows the original OpenID Con¬ 
nect protocol flow - there are no parameter manipulations, 
no redirects to malicious websites and no observation of 
the network traffic between the End-User, the honest OP 
and the Client. Thus, the attack started at the beginning of 
the protocol flow can be neither detected nor prevented by 
any of the participants at this point. 

Phase 3 - The Theft In dependence of the protocol flow. 
Code or Implicit, the messages sent to the attacker differ. 

Within the Code flow the Client redeems the received 
code from the previous phase: It sends the code together 
with the corresponding Client’s credentials received during 
the Dynamic Registration (client_id/ client_secret) to the 
tokenEndp originally specified by the malicious Discovery 
service - in this example http://malicious.com, see Listing 2. 

Since the Implicit flow does not use the tokenEndp, 
the attacker is not able to receive the information send in 
phase 2. However, he can use another malicious endpoint - 
userlnfoEndp used in Step 3.3 in Figure 7 to retrieve further 
information about the authenticated user. In the request, the 
Client sends a freshly generated Access Token. As a result, 
the attacker receives this Access Token and is able to access 








































the authorized resources on the OP. 

6.2. Server Side Request Forgery (SSRF) 

A SSRF attack describes the ability of an attacker to 
create requests from a vulnerable web application to the 
application’s Intranet and the Internet. Usually, SSRF is 
used to attack internal services placed behind a firewall 
and not accessible from Internet. In context of OpenID 
Connect, the malicious Discovery service can be used to 
start such attacks in order to (1.) gather information about 
the Intranet infrastructure of the Client, and (2.) disseminate 
attack vectors. 

Setup. The attacker sets up a malicious Discovery service 
returning endpoints called by the Client during the protocol 
flow. The endpoints are URL strings specifying protocol 
(http(s), ftp, smb etc.), port, path, and parameters. Since 
there are no restrictions regarding the URLs, these can point 
to the Intranet infrastructure of the Client. The Client will 
use these URLs and performs HTTP GET requests on them. 
In this manner, the Client can, for example, be enforced to 
invoke internal REST-based web services. This capability 
of the attacker is considered by the attacker model, since 
the attacker is able to use his UA and send arbitrary HTTP 
requests to every publicly available domain. Thus, he can 
cause the Client to establish connection with the malicious 
Discovery service. 

Attack description. In comparison to the Malicious End¬ 
point attack, now the attacker initiates the OpenID Connect 
authentication on the Client by entering his identity (e.g. 
oskar@malicious.com). Thus, no CSRF attack is needed. In 
the end of the Discovery phase, the malicious Discovery 
service returns the malicious endpoints called during the 
different phases of the protocol. Previous researches reveal 
how the execution of URLs can be used to (1.) connect and 
execute commands on different services like Memcached, 
(2.) Port scanning and (3.) data retrieving [4], [28]. 

6.3. Code Injection Attacks 

User’s input sent through the web interface of the Client 
is usually treated as untrusted and thus filtered to prevent 
attacks like Cross-Site-Scripting (XSS) and SQL-Injection. 
In order to bypass the existing filter an attacker can use other 
channels to inject the attacks vectors - for instance within 
the server-to-server communication in Phase 3. 

Setup. The attacker configures his server to inject malicious 
content in the messages returned in Step 3.2 (e.g. in the ID 
Token) or in Step 3.4 (informations about the authenticated 
user), which are sent to Client in Phase 3 (see Figure 2). 
Please note that the ID Token and Access Token returned 
by the malicious server are valid according to the specifica¬ 
tion, since there are no restrictions regarding the values of 
parameters like “sub”, “name” or “preferred_usemame”. 

Attack description. Initially, the attacker starts the OpenID 
Connect authentication on the Client by entering his identity 


(e.g. oskar@malicious.com). He proceeds with the protocol 
execution until Steps 3.1 and 3.3. The malicious server 
then responds with valid tokens (ID Token and Access 
Token) containing the attack vectors. A toy example of such 
attack vector is shown in Listing 3 where an XSS attack 
vector is injected into the field presenting the name of an 
authenticated user in Step 3.4. 


{ 

"sub": "90342.ASDFJWFA", 

"name": "<script>alert(1)</script>" , 
"preferred_username": "admin", 

"email": "bob@malicious.com" , 

"email_verified" :true 

} 




Listing 3: An example of an XSS attack vector hidden 
in the "name" filed within an Access Token. 


Now, the placed XSS attack vector is stored in the web 
application (persistent XSS). Other webpages on the client 
will use it, for example on a guestbook page, and embed 
the code, so that other page visitors get harmed. The same 
schema can be used to place SQL-Injection attack vectors. 

6.4. Denial-of-Service (DoS) Attacks 

By applying DoS attacks the attacker allocates resources 
on a Client and negatively affects its workflow. Such re¬ 
sources are CPU usage, network traffic or memory. The 
attack can target one or multiple of these resources during 
the execution of DoS attack. 
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(a) Memory usage on the Client within 5 parallel OpenID Connect 
authentication flows to an honest OP. 



(b) Memory usage on the Client within 5 parallel OpenID Connect 
authentication flows to a malicious Discovery service pointing to a 
large file (in this case, we used a Debian Linux image file with 
3.7GB). 

Figure 8: Direct comparison between the memory usage 
on the Client using (a) an honest OP and a (b) malicious 
Discovery service. 

Setup. The setup is similar to the SSRF attack - the attacker 
sets up a malicious Discovery service returning endpoints 






















called by the Client during the protocol flow. The attacker 
is able to use his UA and send HTTP request to the Client 
causing the Client to establish connection with the malicious 
Discovery service. 

Attack description. An attack can be started by using a 
malicious endpoint pointing to a large data file, which will 
be downloaded. The Client calls later on the malicious 
endpoint URL, allocates network resources as well as large 
amount of the memory, which will be unnecessarily used. 

We provide a measurement shown in Figure 8 on an 
Apache Tomcat server with 1280 MB memory and 4x2.4 
Ghz CPU. In Figure 8a we first measured the memory 
usage on the Client within five parallel OpenID Connect 
protocol runs with an honest OP. Once can say that almost 
imperceptible changes in the memory consumption occur. 
In Figure 8b we repeated the same tests, but this time we 
used our malicious Discovery service pointing to a large 
file. After few seconds, the memory usage increased almost 
threefold. After 60 seconds, the Client was not accessible 
for any incoming requests. 

7. Implementation 

We implemented a web service that is publicly available 
on http://ssoattacks. org/OIDC_MaliciousDiscoveryService/ 
and it can be used by Clients for verifying the security 
against the attacks described in Section 6. In order to avoid 
misuse we do not provide tests for DoS, SSRF and injection 
attacks. 

The service contains the following informations: (1.) At¬ 
tack description presenting the main concept of Malicious 
Endpoints. (2.) A Demo showing a normal OpenID Connect 
flow and additionally the broken End-User authentication 
attack described in Section 6.1. For that purpose we config¬ 
ured an honest Client and an honest OP. The usage of own 
Clients is supported by the service. (3.) The configuration 
of the malicious Discovery service, enabling the view on 
the used malicious endpoints. (4.) Database viewing all 
collected credentials. 

Testing Clients. Security auditors can test their Clients by 
using our service. No pre-configuration or installation of any 
software is needed. 

In order to start the security evaluation, the auditor 
has to enter the URL of our malicious Discovery ser¬ 
vice on the target Client - http://ssoattacks.org/OIDC_ 
MaliciousDiscoveryService/. The Client calls the malicious 
Discovery service and caches the metadata returned by it. 
The metadata contains now the malicious endpoints. The 
Client proceeds with the OpenID Connect protocol flow and 
starts the next phases. At the end, the service prints out a 
report that includes all stolen information, see Figure 9, for 
example, the stolen code, accessjtoken, idjtoken and Client 
credentials. Security auditors can use it to test arbitrary 
Clients and evaluate the impact of the attack. 

We tested the Client applications of MITREidCon- 
nect and phpOIDC and attacked them successfully with 
our attacks. An online demo Client is also available 


for testing, see run demo on http://ssoattacks.org/OIDC. 
MaliciousDiscoveryService/. 
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Figure 9: The implementation collects all stolen tokens and 
credentials and prints out a report containing the results. 
Thus, security auditors can test their Clients and evaluate 
the results of the tests. 

8. Countermeasures 

During our search for applicable countermeasures, we 
tried to And a solution requiring minimal changes to the 
protocol and to the existing implementations. In the follow¬ 
ing, we present four possible countermeasures to our attacks 
and discuss the advantages and disadvantages. Noteworthy 
is the fact that each countermeasure mitigates only partially 
the existing issues. Thus, a combination of the proposed 
countermeasures is needed to improve the security on the 
Client. 

OPs Whitelisting. A suitable option to prevent the Mali¬ 
cious Endpoints attack is to whitelist the allowed OPs on 
Client side. By this means, an attacker will not be able to 
start the authentication process with his Discovery service. 
As shown in Figure 10, the administrator of the Client 
should manually whitelist the URL of each OP when it re¬ 
ceives a discovered URL in Step 1.1.2 (the href parameter). 

If the whitelisting approach is applied suitable, the at¬ 
tacker can only influence the first two messages of the 
discovery phase. After Step 1.1.2, the Client compares the 
returned href value with the stored values and breaks the 
execution in case that the URL is unknown. 

Whitelisting mitigates both the Malicious Endpoints and 
the SSRF attack. This countermeasure however limits the 
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Figure 10: A whitelist verification after Step 1.1.2. during 
the Discovery phase. The returned href value is compared 
with the entries in the database and in case that it is 
whitelisted the Client proceeds with the Discovery. 


flexibility of the Client and reduces the support of custom 
OPs, which, depending on the according Client, could cause 
problems. Additionally, the management overhead regarding 
the provided whitelist can lead to further problems. 

Endpoint Restrictions. A similar approach to prevent the 
attack would be to restrict the possible contents of the 
tokenEndp according to the contents of the authEndp. For 
example, it could be required that the tokenEndp MUST be 
located on the same domain as the authEndp and may only 
differ in subdomain and/or path. This way, an honest Client 
receiving a Discovery response can detect this attack and 
abort the protocol. 

Even though this countermeasure restricts the introduced 
attack, it does not mitigate it completely. In case the at¬ 
tacker runs his malicious Discovery service on the same 
Infrastructure-as-a-Service cloud environment as the honest 
OP, he could bypass this proposed countermeasure by using 
the same domain or subdomain. 

DoS protection. In order to prevent DoS the Client could 
simply do an HTTP HEAD request — before doing a GET 
request — and check the Content-Length HTTP header. In 
this way, the Client can retrieve the size of the file. Please 
note that this will only work on benign HTTP servers. 
The attacker could prepare his own Webserver that responds 
with a wrong Content-Length header if a HEAD request 
receives. To protect against this, the implementation should 
stop downloading files after receiving a specified number of 
Bytes (e.g. SMB). 


Client authentication via client_secretJwt or pri¬ 
vate _key Jwt. During the attack described in Section 6.1, the 
attacker steals the client_id/client_secret of the Client in step 
3.1 (see Figure 7). In order to mitigate the attack, the Client 
can use alternatively the client_secret Jwt or private Jcey Jwt 
flow for authentication in Phase 3 [36, Section 9]. Within 
both flows, the Client does not send the client_secret through 
the channel. The client signs a ISON message by using 
either the client_secret or an asynmietric private key. The 
OP verifies the message with the corresponding key and 
authenticates the Client. 

Just signing the message does not mitigate the at¬ 
tack since the attacker can reply it on the honest toke¬ 
nEndp. According to the specification the JSON message 
includes an audience parameter specifying the URL of 
the tokenEndp. During the attack the audience points to 
http://malicious.com. Thus, the attacker can steal the code 
and the signed JSON message, but he cannot replay them 
on the honest tokenEndp since it will detect the different 
values. 

Please note that DoS and SSRF attacks are still possible 
and should be considered by the implementation of the 
Client. 

Binding Discovery and Client Registration Phase. We 

discussed our findings with the OAuth Working group. As 
a result, the OAuth specification will be extended in such a 
way that the Discovery phase is bound to the Authentication 
Response sent in Phase 2. We depicted this approach in 
Figure 11. 
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Figure 11: Binding Phase 1.1 (Discovery) and 2.3 (Authen¬ 
tication Response) via the issuer element. 


CSRF/Clickjacking protection. Our attack to break the 
End-User authentication (cf. Section 6.1) requires the in¬ 
jection of the malicious identity (e.g. alice@malicious.com) 
in the first step, see Figure 7. 

To prevent this kind of attack, we propose each client to 
implement a proper CSRF^ and Clickjacking protection^. 

Please note that this will only prevent the broken End- 
User attack. SSRF, code injection, and DoS is still possible, 
because for this kind of attacks, the attacker itself sends a 
login request with alice@malicious.com. 

4. https://www.owasp.org/index.php/Cross-Site_Request_Forgery_ 
(CSRF)_Prevention_Cheat_Sheet 

5. https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet 


The protocol flow is the same to its current specification 
with only one small change: In Step 2.3, we added the issuer 
value as an additional parameter. Now, the Client is able to 
detect the attack since the issuer in the Discovery document 
is http://malicious.com (cf. Listing 2), but the honest OP 
responds with its value https://honestOP.com. 

This countermeasure requires a very small extension 
of the current protocol flow and additional checks on the 
OP, but in comparison to the previous approaches, it offers 
the full flexibility of the Discovery and Dynamic Client 
Registration extensions. 

This countermeasure does not prevent DoS and SSRF 
attacks and should be considered by the implementation of 





















































the Client. 

Summary. By implementing CSRF and Clickjacking coun¬ 
termeasures on the Client the attack described in Section 6.1 
will be mitigated. However, we believe that more general 
and protocol-based solution should be provided by the 
OpenID Connect specification. Thus, we prefer the coun¬ 
termeasure binding the Discovery and Client Registration 
Phase. Additionally, we advise the usage of both flows 
client_secretJwt or private_keyjwt for Client authentica¬ 
tion avoiding the transmission of the client_secret between 
the Client and the OP. 

In order to reduce the impact of DoS attacks, the Client 
should expect short messages. Thus, it can be configured to 
wait small period for an answer and accepts messages less 
than several KBytes. The Client should restrict the usage 
of URLs, protocols and Ports in order to reduce the attack 
surface of SSRF attacks. For instance only HTTP requests 
with destination port 443 or 80 should be allowed. 

9. Related Work 

Attacks on SSO systems. In 2012, Wang et al. [41] concen¬ 
trated on real-life SSO and the analysis of SSO protocols and 
implementation flaws via Browser related messages (BRM). 
The authors have well demonstrated the problems related to 
token verification with different attacks. Additionally, they 
introduced a tool named BRM-Analyzer, which analyses the 
traffic passing through a user’s browser and detects abnor¬ 
malities in the protocol flow, attempting to notice attacks. 
However, since the Malicious Endpoints attack described in 
this paper follows the protocol specification, no abnormali¬ 
ties can be detected by tools like BRM-Analyzer. Moreover, 
the BRM-Analyzer cannot observe the communication dur¬ 
ing the Discovery and Dynamic Registration phase, since 
the communication between Client and OP occurs directly 
and not via the End-User’s browser. 

In 2012, Sun et al. [34] analyzed nearly 100 OAuth 
implementations, and found serious security flaws in many 
of them. The research focused on the impact of classical 
web attacks like XSS, CSRF and TLS misconfiguration 
on the OAuth implementations. In [12], [13], [14], [25], 
[26], [44], further attacks on OAuth implementations were 
discovered and reported. However, all these works concen¬ 
trated on individual attacks and especially implementation 
misconfiguration. 

In 2013, Wang et al. introduced a systematic process 
for identifying critical assumptions in SDKs, which led to 
the identification of exploits in constructed Apps resulting in 
changes in the OAuth specification [42]. Chen et al. revealed 
in 2014 serious vulnerabilities in OAuth applications on 
mobile devices caused by the developer’s misinterpretation 
of the OAuth protocol [9]. 

In 2014 Cao et. al. studied vulnerabilities in existing 
SSO protocols that allow impersonation attacks and an¬ 
alyzed the main reasons leading to these flaws [8]. The 
authors concentrated only on phase 2 and phase 3 of the SSO 
protocol flow and did not consider phase 1. Interestingly, the 


authors of the paper recognized that one main problem in 
SSO is the lack of authentication between the OP and Client, 
which is part of the Malicious Endpoints attack. 

Please note that none of the previous papers considers 
the OpenID Connect protocol flow and the Discovery and 
Dynamic Registration phases. 

Formal approaches. An open problem that we see as 
important future work (see below) is the introduction of 
a formal language and an verifier tool that will be able 
to automatically detect vulnerabilities as described in this 
paper. In 2012 Sun et al. [35] provided a semi-automated 
analysis on OpenID by modeling CSRF, replay, imper¬ 
sonation, parameter forgery and session swapping attacks. 
However, the authors did not consider that any of the OP’s 
components can act maliciously (e.g. the Discovery service). 
In 2014 Fett et al. [15] introduced a formalization for the 
(now defunct) SSO service BrowserlD. Nevertheless, in this 
formal model they still perform a manual security analysis. 

We refrain from modeling OpenID Connect in such 
a formal model for two reasons: (1) We believe that a 
thorough understanding of (second-order) vulnerabilities is 
essential to developing a formal model for automated analy¬ 
sis, and therefore concentrate on readability. (2) The model 
from [15] depicts only BrowserlD and thus has to be mod¬ 
ified for each SSO protocol separately. 

Second-order vulnerabilities. In 2014 Dahse et. al. in¬ 
troduced an approach for static detection of second-order 
vulnerabilities in web applications [11]. The authors con¬ 
sidered attacks like SQL-Injection and XSS and methods to 
prevent such vulnerabilities. More complex attacks including 
multiple steps for injecting attack vectors and their execu¬ 
tion in distributed systems interacting with each other were 
not considered. One year later Olivo et.al. introduced new 
class of DoS attacks referred to the second-order vulner¬ 
abilities [27]. Additionally, the authors developed a static 
analysis approach for detecting second-order DoS vulner¬ 
abilities in web applications. More complex systems, for 
example distributed systems like SSO, were not considered 
and analyzed. 

10. Discussion and Future Work 

In this paper, we analyzed the OpenID Connect protocol 
considering all phases of the protocol. During analyzing the 
OpenID Connect’s the Discovery and Dynamic Registration 
phases we found several novel second-order vulnerabilities 
resulting in broken user authentication, DoS, SSRF and 
injection attacks. Summarized, we found an existing gap in 
previous security evaluations, since these concentrated only 
on the security critical phases - Phase 2 and Phase 3. 

Speaking of SSO, other protocols like OpenID [33, 
Section 7.3], SAME [10] and BrowserlD [23] support fea¬ 
tures similar to the Discovery and Dynamic Registration 
extensions described in OpenID Connect. It is essential that 
these protocols are further studied to avoid similar security 
gaps. We refer this research to the future work. 


Second-order vulnerabilities in distributed systems like 
SSO are barely studied. The explanation for this gap is the 
complexity of such distributed systems. Since this complex¬ 
ity has not yet been tamed by an automated analysis tool, 
many of the SSO vulnerabilities today are discovered by 
manual security evaluation, which is time consuming and 
inefficient. 

Developing such an automated analysis tool requires 
deep knowledge of the distributed information flows in a 
SSO system, and potential vulnerabilities. In this paper, we 
aim to provide exactly this information for the novel and 
important OpenID Connect SSO protocol, especially for the 
discovery phase. 

An important task in the future is the development of 
techniques and automated tools facilitating the modeling, 
evaluation and detection of security issues in distributed 
systems like SSO. Currently, there is a gap, which should 
be in the scope of further researches. 
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